XZ: Fix incorrect XZ_BUF_ERROR
authorJan Beulich <jbeulich@suse.com>
Thu, 22 Sep 2011 17:34:27 +0000 (18:34 +0100)
committerJan Beulich <jbeulich@suse.com>
Thu, 22 Sep 2011 17:34:27 +0000 (18:34 +0100)
commitfefc3f0274acba5b806fa46917a6130c0dcbb7f2
tree0171496bfae32b6df07c27e4401858a974df3cc7
parentec595a6f1c63fbb461bd7f217b71df1cb6a6a994
XZ: Fix incorrect XZ_BUF_ERROR

From: Lasse Collin <lasse.collin@tukaani.org>

xz_dec_run() could incorrectly return XZ_BUF_ERROR if all of the
following was true:

 - The caller knows how many bytes of output to expect and only
   provides
   that much output space.

 - When the last output bytes are decoded, the caller-provided input
   buffer ends right before the LZMA2 end of payload marker.  So LZMA2
   won't provide more output anymore, but it won't know it yet and
   thus
   won't return XZ_STREAM_END yet.

 - A BCJ filter is in use and it hasn't left any unfiltered bytes in
   the
   temp buffer.  This can happen with any BCJ filter, but in practice
   it's more likely with filters other than the x86 BCJ.

This fixes <https://bugzilla.redhat.com/show_bug.cgi?id=3D735408>
where Squashfs thinks that a valid file system is corrupt.

This also fixes a similar bug in single-call mode where the
uncompressed size of a block using BCJ + LZMA2 was 0 bytes and caller
provided no output space.  Many empty .xz files don't contain any
blocks and thus don't trigger this bug.

This also tweaks a closely related detail: xz_dec_bcj_run() could call
xz_dec_lzma2_run() to decode into temp buffer when it was known to be
useless.  This was harmless although it wasted a minuscule number of
CPU cycles.

Signed-off-by: Lasse Collin <lasse.collin@tukaani.org>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
xen/common/xz/dec_bcj.c